Red Hat System Administration II 8.2

Планирование повторяющихся системных заданий

Задачи

После завершения этого раздела вы сможете планировать выполнение команд по повторяющемуся расписанию с помощью системного файла и каталогов crontab.

Повторяющиеся системные задания

Системным администраторам часто приходится выполнять повторяющиеся задания. Рекомендуется запускать такие задания из системных учетных записей, а не из пользовательских. То есть вместо команды crontab используйте системные файлы crontab для планирования заданий. Записи заданий в системных файлах crontab аналогичны записям в пользовательском файле crontab. Единственное исключение — в системных crontab перед полем команды есть дополнительное поле, в котором указан пользователь, от имени которого должна выполняться команда.

В комментариях в файле /etc/crontab есть полезная синтаксическая диаграмма.

 # For details see man 4 crontabs

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue ...
# |  |  |  |  |
# *  *  *  *  * user-name  command to be executed

Повторяющиеся системные задания определяются в двух местах: в файле /etc/crontab и файлах каталога /etc/cron.d/. Вы всегда должны создавать свои собственные файлы crontab в каталоге /etc/cron.d для планирования повторяющихся системных заданий. Поместите пользовательский файл crontab в /etc/cron.d, чтобы защитить его от перезаписи в случае обновления пакета у поставщика /etc/crontab, в результате которого содержимое /etc/crontab может быть перезаписано. Пакеты, которым требуются повторяющиеся системные задания, размещают свои файлы crontab в файле /etc/cron.d/, содержащем записи заданий. Администраторы также используют это расположение для группирования связанных заданий в одном файле.

В системе crontab также есть репозитории для сценариев, которые должны запускаться каждый час, день, неделю и месяц. Эти репозитории представляют собой каталоги /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/ и /etc/cron.monthly/. Эти каталоги содержат исполняемые сценарии командной оболочки, а не файлы crontab.

Важно

Сценарии, помещаемые в эти каталоги, должны быть исполняемыми. Если сценарий не является исполняемым, он не будет выполнен. Чтобы сделать сценарий исполняемым, используйте команду chmod +x script_name.

Команда run-parts, вызываемая из файла /etc/cron.d/0hourly, запускает сценарии /etc/cron.hourly/*. Команда run-parts также выполняет ежедневные, еженедельные и ежемесячные задания, но она вызывается из другого файла конфигурации ― /etc/anacrontab.

Примечание

В прошлом для обработки файла /etc/anacrontab использовалась отдельная служба anacron, но в Red Hat Enterprise Linux 7 и более поздних версиях этот файл обрабатывает стандартная служба crond.

Назначение файла /etc/anacrontab — обеспечить выполнение важных заданий, чтобы они случайно не были пропущены из-за выключения или гибернации системы. Например, если ежедневное системное задание не было выполнено из-за перезагрузки системы, оно будет выполнено при возобновлении работы системы. Однако возможна задержка запуска задания в несколько минут в зависимости от значения параметра Delay in minutes, указанного для задания в файле /etc/anacrontab.

В /var/spool/anacron/ есть файлы для каждого из ежедневных, еженедельных и ежемесячных заданий. По ним можно определить, было ли выполнено конкретное задание. Когда демон crond запускает задание из /etc/anacrontab, он обновляет метки времени этих файлов. Та же метка используется для определения времени последнего выполнения задания. Синтаксис файла /etc/anacrontab отличается от обычных файлов конфигурации crontab. Каждая строка этого файла содержит четыре поля, которые описаны ниже.

  • Период в днях

    Интервал в днях для задания, которое выполняется по повторяющемуся графику. Это поле принимает целое число или макрос в качестве значения. Например, макрос @daily эквивалентен целому числу 1, то есть задание выполняется ежедневно. Точно так же макрос @weekly эквивалентен целому числу 7, то есть задание выполняется еженедельно.

  • Задержка в минутах

    Период времени до запуска задания демоном crond.

  • Идентификатор задания

    Уникальное имя для идентификации задания, например в log-файлах.

  • Команда

    Команда, которую необходимо выполнить.

Файл /etc/anacrontab также содержит объявления переменных среды с использованием синтаксиса ИМЯ=значение. Особый интерес представляет переменная START_HOURS_RANGE, которая указывает временной интервал выполнения заданий. Задания не запускаются вне этого диапазона. Если в какой-то день задание не будет выполнено в этот промежуток времени, следующий запуск задания состоится только на следующий день.

Таймер systemd

С появлением systemd в Red Hat Enterprise Linux 7 стала доступна новая функция планирования заданий: юниты таймера systemd. Юнит таймера systemd активирует еще один юнит другого типа (например, службу), имя которого совпадает с именем юнита таймера. Юнит таймера обеспечивает активацию других юнитов по времени. Для упрощения отладки systemd регистрирует события таймера в системные журналы.

Пример юнита таймера

Пакет sysstat предоставляет юнит таймера systemd с именем sysstat-collect.timer для сбора системной статистики каждые 10 минут. В следующем выводе показаны строки конфигурации файла /usr/lib/systemd/system/sysstat-collect.timer.

...output omitted...
[Unit]
Description=Run system activity accounting tool every 10 minutes

[Timer]
OnCalendar=*:00/10

[Install]
WantedBy=sysstat.service

Параметр OnCalendar=*:00/10 указывает, что этот юнит таймера активирует соответствующий юнит (sysstat-collect.service) каждые 10 минут. Однако можно указывать более сложные интервалы времени. Например, значение 2019-03-* 12:35,37,39:16 параметра OnCalendar заставляет юнит таймера активировать соответствующий юнит службы в 12:35:16, 12:37:16 и 12:39:16 каждый день в течение марта 2019 года. Вы также можете указывать относительные таймеры с помощью таких параметров, как OnUnitActiveSec. Например, опция OnUnitActiveSec=15min заставляет юнит таймера активировать соответствующий юнит через 15 минут после последней активации.

Важно

Не изменяйте файл конфигурации юнита в каталоге /usr/lib/systemd/system, поскольку любое обновление пакета поставщика, влияющее на файл конфигурации, может перезаписать изменения конфигурации, внесенные вами в этот файл. Поэтому создайте в каталоге /etc/systemd/system копию файла конфигурации юнита, который необходимо изменить, и отредактируйте эту копию, чтобы сделанные вами изменения конфигурации юнита не перезаписывались обновлениями пакета поставщика. Если в каталогах /usr/lib/systemd/system и /etc/systemd/system есть два файла с одинаковыми именами, systemd обработает файл в каталоге /etc/systemd/system.

Изменив файл конфигурации юнита таймера, выполните команду systemctl daemon-reload, чтобы убедиться, что systemd видит изменения. Эта команда перезагружает конфигурацию диспетчера systemd.

[root@host ~]# systemctl daemon-reload

Перезагрузив конфигурацию диспетчера systemd, выполните следующую команду systemctl, чтобы активировать юнит таймера.

[root@host ~]# systemctl enable --now <unitname>.timer

Ссылки

Man-страницы crontab(5), anacron(8), anacrontab(5), systemd.time(7), systemd.timer(5) и crond(8)